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Description 

Method and Apparatus for Feature 
Rights Management in a Multilevel 

Hierarchy 

Background of Invention 
[New Section Title] 

[0001] 1. Technical Field 

[0002] The present invention relates to feature rights manage- 
ment and, more particularly, relates to the multilevel hier- 
archy for management and distribution of feature rights. 

[0003] 2. Description of the Related Art 

[0004] Systems have been known for activating digital rights such 
as in software using digital keys. Digital keys have been 
used to allow installation of a software application at the 
time of software installation. Digital keys have also been 
used to encode classes of rights for digital media file such 
as music. Digital key mechanisms have also been used to 
unlock certain features in software applications. 



[0005] An example of a digital key mechanism used to unlock 

certain features in software applications is the Total Con- 
trol 1000 WAN HUB Network Management Card by U.S. 
Robotics. The U.S. Robotics Total Control 1000 provided 
for feature upgrades to network management and appli- 
cation cards. Examples of the features to be upgraded 
were dial security and cellular support as well as future 
features upgrades. The Total Control 1000 was a chassis 
consisting of one network management card and up to 16 
application cards, each application card providing, for ex- 
ample, analog modem dial-up access lines for an internet 
service provider ISP. The analog modems on each network 
application card had features enabled by keys. The Total 
Control 1000 chassis was capable of receiving keys from a 
management application connected through a serial port. 
The management application sent their feature keys over 
a Simple Network Management Protocol SNMP channel. 
These keys were input directly to a card in the Total Con- 
trol 1000 chassis by a technician. Each key was con- 
structed using the serial number of the destination card, 
so that it would be tied directly to a serial number of the 
card which the feature is destined. The Total Control 1000 
keys could not be reassigned to other cards. This made 



card replacement maintenance difficult because keys 
could not be reused. 
[0006] a way of automatically managing feature permissions 

during maintenance on site at chassis is needed. What is 
also needed is a way for an operator to manage the distri- 
bution of keys without the keys being tied to specific 
cards yet not require communications with a remote 
server every time a card or feature was configured in the 
field in a facility. It is also desired to distribute feature 
permissions more efficiently using authenticated keys. A 
more efficient way of allocating feature keys for an equip- 
ment operator among different facilities and multiple 

chassis of an operator is needed. 
Summary of Invention 

[0007] a multilevel hierarchical feature rights management sys- 
tem provides an efficient way of allocating feature keys for 
an equipment operator among different facilities and ap- 
plication equipment is provided. The feature rights man- 
agement system has a feature rights server with a reposi- 
tory for storing feature keys, the feature keys representing 
activation rights for features. A feature rights manage- 
ment agent receives feature keys from the feature rights 
server, stores feature rights in a repository, and identifies 



available feature units. A sub-agent requests feature 
rights from the feature rights management agent. The 
feature rights management agent allocates the feature 
units among requesting sub-agents. 
[0008] The details of the preferred embodiments of the invention 
will be readily understood from the following detailed de- 
scription when read in conjunction with the accompanying 

drawings wherein: 
Brief Description of Drawings 

[0009] FIG. 1 illustrates a block diagram of the multilevel hierar- 
chy of the feature rights management system of the 
present invention; 

[0010] FIG. 2 illustrates a diagram of an embodiment of the 

present invention having a plurality of application cards, 
at least one system manager card and a feature rights 
server; 

[001 1] FIG. 3 illustrates a diagram of an example of a feature key 
file containing the feature keys of the present invention; 

[0012] FIG. 4 illustrates a flowchart of a method where a sub- 
agent requests feature permissions from a feature rights 
management agent; 

[0013] FIG. 5 illustrates a flowchart of a method where a feature 
rights management agent requests feature keys from a 



feature rights server; 

[0014] FIG. 6 illustrates a flowchart of a method where a sub- 
agent releases feature permissions to a feature rights 
management agent; and 

[0015] FIG. 7 illustrates a flowchart of a method where a feature 
rights management agent releases feature keys to a 
server. 

[0016] 

Detailed Description 

[0017] FIG. 1 illustrates a block diagram of the multilevel hierar- 
chy of the feature rights management system 100 of the 
present invention. A number of feature rights manage- 
ment agents 120 are coupled over a network 130 to a 
feature rights server 110. The feature rights server 110 
contains a memory for storing network feature keys. Each 
network feature key represents rights for features that are 
stored in the feature rights management server 110 for 
subsequent allocation to any feature rights management 
agent 120 in the operator's network. 

[0018] a plurality of sub-agents 140 are connected over a bus 
150 to its corresponding feature rights management 
agent 120. In a telecommunications deployment, each 



feature rights management agent 120 is typically located 
in one facility among a plurality of sub-agents 140. A plu- 
rality of sub-agents 140 can be located in a single chassis 
and share a common bus on a backplane of a chassis or 
the plurality of sub-agents 140 can be located in multiple 
chassis all communicating with a single feature rights 
management agent 120 over a networked bus such as an 
ethernet bus. The plurality of sub-agents 140 and corre- 
sponding agents 120 can even be connected over a net- 
worked bus rather than a backplane bus without any 
chassis. This arrangement might exist within a single 
general purpose computing platform such as a UNIX 
server when the capabilities of a single server can support 
the application demands of a system. 
[0019] An operator obtains feature keys, designated as network 
keys, from an equipment provider and stores these fea- 
ture keys in the feature rights server 110. Each feature key 
designates a kind of feature, a number of permissible 
units for that feature, and a destination ID such as a serial 
number for the server to which the feature is permitted. 
Each kind of feature can designate a single feature or 
preferably groups of features. Element keys are also gen- 
erated by the server 110 with a designation of a kind of 



feature, a number of permissible units for that feature, 
and a destination ID such as a serial number for the agent 
to which the feature is permitted. A digital authentication 
signature is also contained in each feature key regardless 
of whether or not it is a network key or an element key. 
The feature rights server 110 is a repository for feature 
keys which have not yet been used to activate features. 

[0020] An example of a feature to be permitted is prepaid billing. 
Telecommunication calls are typically billed after a call is 
made. A new kind of payment for telecommunications 
calls occurs in advance. This prepaid billing feature can be 
set up as a feature requiring a feature key before a pre- 
paid billing feature is permitted in the software of the 
sub-agent 140. The number of permissible units for this 
feature would designate the number of application cards 
that are permitted to use this prepaid billing feature. Al- 
ternatively the number of permissible units for this feature 
can designate the number of simultaneous telephone calls 
that are permitted using this prepaid billing feature. 

[0021] when an operator desires to provision or activate equip- 
ment, activation of the equipment is initiated in the facility 
at a sub-agent 140. The sub-agent 140 then requests 
permission from the feature rights management agent 



120 to activate a kind of feature and a requested number 
of units for that feature. The feature rights management 
agent 120, upon receiving a request from a sub-agent 
140, checks to see a number of available feature units for 
a particular feature stored in its memory. If the feature 
rights management agent 120 needs more rights than are 
stored in its memory, the agent 120 sends a request to 
the feature rights server 110 to obtain more feature keys. 
The feature rights server 110 then subtracts units from its 
available feature keys, assembles element keys and sends 
these thus assembled element feature keys to the re- 
questing feature rights management agent 120. The fea- 
ture rights management agent 120 then subtracts units 
from its available allocation of feature units and sends an 
authorization to the requesting sub-agent 140. 
[0022] For a telecommunications application feature, when a 
sub-agent 140 is on standby between calls, its feature 
rights are retained within the sub-agent. When a sub- 
agent is re-provisioned or re-activated, such as when an 
application card is replaced or redeployed, its feature 
rights can be released from the sub-agent 140 to the fea- 
ture rights management agent 120. The agent 120 stores 
those rights for redeployment to other sub-agents 140 or 



release to the feature rights server 110. When the feature 
rights management agent 120 stores rights for re- 
deployment, the feature rights management agent 120 
can store the rights for redeployment to any sub-agent 
140. In the case of a chassis arrangement, when an appli- 
cation card sub-agent is replaced in a slot of a chassis, 
unless the chassis has been re-provisioned, rather than 
store the rights for redeployment to any sub-agent 140, it 
is desired for the feature rights management agent 120 to 
store those rights associated with the slot in the chassis. 
Then, when a replacement application card arrives in the 
slot, the same rights are allocated to that sub-agent. 
[0023] The agent 120 and the sub-agent 140 do not require au- 
thenticated keys in order to authorize features for opera- 
tion in the sub-agents 140. While the connection between 
the feature rights server 110 and the plurality of agents 
120 requires authenticated keys, the relationship between 
the plurality of sub-agents 140 and its respective agent 
120 is a trusted relationship and does not require authen- 
ticated keys. The agent 120 allocates rights among its 
sub-agents 140 as needed without an accounting to the 
feature rights server 110 other than the number of units 
and kind of features activated. The feature rights server 



110 still knows which agents 120 obtained rights. 

[0024] | t j S not currently contemplated, however, that the feature 
rights server 110 has the power to revoke rights, nor is it 
contemplated that the feature rights management agents 
120 have the power to revoke rights. Rather, rights are 
released voluntarily by the sub-agents 140 and returned 
back to their respective feature rights management agents 
120 when no longer needed. The sub-agents 140 release 
rights when no longer needed to perform its provisioned 
operation. Provisioning of the sub-agents 140 occurs by 
operator intervention over a protocol or command line in- 
terface. The feature rights server 110 does not re- 
provision the feature rights management agents or sub- 
agents or require release of rights. Once provisioned, 
sub-agents request keys to activate features via the mul- 
tilevel hierarchy of the present invention. 

[0025] FIG. 2 illustrates a diagram of an embodiment of the 

present invention having a plurality of application cards 
240, at least one system manager card 220 and a feature 
rights server 210 according to an embodiment of the 
present invention. A chassis 260 holds a plurality of ap- 
plication cards 240 and is capable of holding a system 
manager card 220. In a facility more than one chassis 260 



can be deployed. In the event more than one chassis is 
deployed, only one system manager is needed. The fea- 
ture rights server 210 communicates over a network 230 
with the system manager card 220 in the facility. Typically 
the feature rights server 210 is located in a different city 
or building from the facility with the various chassis 260. 
The system manager card 220 receives element feature 
keys from the feature rights server 210 over the network 
230. The application cards 240 then request permission 
to activate features from the system manager card 220. It 
is noted that the present invention is applicable to ar- 
rangements other than chassis structures with application 
cards. For example the sub-agents can be virtual software 
components operating on general-purpose computing 
platforms alongside a software feature rights manage- 
ment agent which provides permissions in a trusted envi- 
ronment. The feature rights server 210, however, would 
be located in a remote central location and needs digital 
authentication signature and its feature keys. 
[0026] FIG. 3 illustrates a diagram of an example of a feature key 
file 320 containing the feature keys of the present inven- 
tion. A plurality of feature keys 310 makeup a feature key 
file 320. Each feature key 310 contains a feature ID, a 



number of feature units, a destination identifier (such as a 
serial number or identifier for a feature server or feature 
rights management agent), a type of either element or 
network and a digital authentication signature. 

[0027] Because the relationship between the feature rights man- 
agement agent and sub-agent is trusted, permissions and 
not keys are communicated between the agent and sub- 
agents. These permissions do not contain a destination 
identifier or a digital authentication signature because 
they do not need the extra security provided by them in a 
key. The feature key file 320 can be encoded using Exten- 
sible Markup Language XML which provides a containment 
mechanism where each key 310 and its contents are 
uniquely identified by XML tags. 

[0028] The feature rights server 110 is allowed to divide the fea- 
ture units provided for in a key 310. For example, six fea- 
ture units for a Feature ID of 10 can be allocated among 
two agents 120. For instance, a first agent 120 may re- 
ceive three feature units for the feature ID 10 and a sec- 
ond agent 120 may receive one feature unit for this Fea- 
ture ID 10 while the feature rights server 110 retains the 
remaining two feature units for the illustrated Feature ID 
10. Once the feature rights server divides the units, it as- 



sembles a feature key 3 10 with a type designation of "ele- 
ment" as illustrated in FIG. 3. The "element" type designa- 
tion identifies that the feature key now assembled by the 
feature server is a key for a feature rights management 
agent. The key 310 assembled by the feature rights server 
also specifies a destination ID for the feature rights man- 
agement agent, the number of feature quantity units and 
the feature type of the key. The feature rights manage- 
ment agent does not assemble feature keys for delivery to 
the sub-agents. The feature rights management agent 
just provides permission to the sub-agents. Nevertheless, 
when the feature rights management agent returns fea- 
ture rights to the feature server, the feature rights man- 
agement agent assembles a key for their return. 
[0029] The digital authentication signature of each feature key 
310 is calculated using a hash function on the feature ID, 
feature units and destination identifier. This digital au- 
thentication signature also provides a secure authentica- 
tion with the key source and also provides the same bene- 
fits as a checksum. The hash function can be any function 
that takes message authentication codes and combines 
them with a secret keyword. One preferred example of a 
hash function is the MD5 Keyed-Hash Message Authenti- 



cation Code (HMAC MD5) and other kinds such as HMAC 
SHA-1 or HMAC RIPEMD can be used. A security parame- 
ter index can be contained in the feature key to identify 
the kind of hash or encryption function used to encode 
and decode the authentication signature. 
[0030] FIG. 4 illustrates a flowchart of a method where a sub- 
agent requests feature permissions from a feature rights 
management agent. An operator first sets up a sub-agent 
at step 410 by loading application software into the sub- 
agent such as an application card of the chassis in the 
preferred embodiment of FIG. 2. Typically all features are 
contained in the application software pre-loaded in a sub- 
agent, but the application software in the sub-agent re- 
quires permission before such features are activated. The 
operator at the facility then in step 410 provisions the 
sub-agent. After provisioning, certain features need per- 
mission. The sub-agent then requests at step 420 per- 
mission from the feature rights management agent for the 
new provisioning. The sub-agent at step 430 then re- 
ceives a message from the feature rights management 
agent notifying the sub-agent that a quantity of feature 
key units for a particular feature as specified by a feature 
ID has been allocated to the sub-agent. The sub-agent at 



step 440 then activates the features using the received 
feature authorizations. 
[0031] FIG. 5 illustrates a flowchart of a method where a feature 
rights management agent requests feature keys from a 
feature rights server. A feature rights management agent 
receives a feature rights request from a sub-agent in step 
510. The feature rights management agent in step 520 
checks its memory for available feature units and deter- 
mines whether units are available. If units are not avail- 
able, the feature rights management agent requests addi- 
tional rights from the feature server as in step 530. The 
server in step 540 receives the request and evaluates the 
available feature rights and creates an element feature key 
and returns that element key to the feature rights man- 
agement agent. The feature rights management agent in 
step 550 validates the contents of the feature key and ac- 
knowledges receipt to the server at which point the server 
updates its memory indicating that the feature rights have 
been allocated. 

[0032] FIG. 6 illustrates a flowchart of a method where a sub- 
agent releases feature permissions to a feature rights 
management agent. An operator re-provisions a sub- 
agent at step 610. The sub-agent in step 620 releases its 



excess permissions to the feature rights management 
agent in response to the re-provisioning. The permissions 
released include its excess feature kind permissions and 
feature quantity permissions. The sub-agent then receives 
a release acknowledgment from the feature rights man- 
agement agent and deletes released permissions from its 
memory at step 630. 
[0033] FIG. 7 illustrates a flowchart of a method where a feature 
rights management agent releases feature keys to a 
server. A feature rights management agent determines 
whether excess feature rights are stored in its memory at 
step 710. The feature rights management agent tracks in 
its memory for each kind of feature a quantity of feature 
units which have not been allocated to sub-agents. The 
feature rights management agent then determines at step 
720 from memory the excess kinds of features and the 
excess quantity units for each kind of feature. Then at 
step 730 the feature rights management agent assembles 
an element feature key using a feature ID and using fea- 
ture quantity units and deletes such rights from its mem- 
ory. The feature rights management agent then sends at 
step 740 the assembled feature key to the feature rights 
server and deletes rights from its memory after receiving 



an acknowledgment from the feature rights server. This 
key sent to the feature rights server from the feature 
rights management agent is an element type of key. 
[0034] Element keys are assembled for communication between 
the feature rights server and an agent. Network keys are 
loaded into the feature rights server when provided by an 
equipment supplier. Because the relationship between the 
feature rights management agent and the sub-agent is a 
trusted relationship, an authentication signature is not 
needed for communication of rights between the feature 
rights management agent and sub-agent. Thus keys are 
not needed and mere permissions can be communicated 
between a feature rights management agent and its sub- 
agents. 

[0035] The present invention allows an operator of a facility to 
add or delete features at the sub-agent level such as by 
interacting directly with an application card in a chassis. 
Feature keys are purchased from an equipment supplier 
and loaded into a central feature rights server which can 
be remotely located. This multilevel hierarchy structure 
allows the rights to be added at a central location and the 
control of features determined at the bottom of the hier- 
archy. This has one advantage of little communication de- 



mand between application software and the feature rights 
server. The application software can have features enabled 
by merely obtaining a quantity units permission for that 
feature from a feature rights management agent located 
in the same facility, chassis or nearby chassis. Thus, com- 
munication over wide area network to a remote server is 
not necessary and reliability is improved. Telecommunica- 
tions equipment should be capable of autonomously re- 
turning to an operational state without the need for au- 
thorizations from a remote node such as a feature rights 
server. Telecommunications networks should not be de- 
pendent upon authorizations from wide area network 
servers anymore than necessary in the event of network 
failure or national crisis. Management by the feature 
rights server is also simplified because the feature rights 
server has knowledge of only what feature rights manage- 
ment agents obtained feature key rights. The feature 
rights server and its operator are not burdened with the 
data of which sub-agents in the facilities have activated 
features. Thus the unique multilevel hierarchy for feature 
rights management having the above advantages is pro- 
vided by the present invention as illustrated in the draw- 
ings and claimed herein below. 



[0036] Although the invention has been described and illustrated 
in the above description and drawings, it is understood 
that this description is by example only, and that numer- 
ous changes and modifications can be made by those 
skilled in the art without departing from the true spirit 
and scope of the invention. Although the examples in the 
drawings depict only example constructions and embodi- 
ments, alternate embodiments are available given the 
teachings of the present patent disclosure. For example 
the embodiment of the feature rights management agents 
and sub-agents does not need to be implemented in any 
particular hardware configuration but could logically be 
separated while physically embodied in the same hard- 
ware. Additionally, while the invention has been illustrated 
as equipment deployed by an operator, other kinds of 
users can benefit from the present invention besides 
telecommunications operators. 

[003 7 ] What is claimed is: 



